rrc

Section: Domain Debug Tools Manual (1)
Updated: May 17 1993
Index Return to Main Contents

NAME

rrc - check DNS resource records

SYNOPSIS

rrc [ msglevel ]

DESCRIPTION

Rrc (resource records check) finds frequent errors in the resource records of DNS databases. It finds some syntax as well as semantic errors, such as detecting:

a): Names without a trailing dot.
b): Hostnames for which there aren't A or CNAME records.
c): The presence of Internet addresses where domain names should be found.
d): IP addresses that don't match with host names (in WKS RRs).
e): The list of name servers of a delegated zone present in its parent zone, doesn't match with the same list in the delegated zone.
f): Using localhost and loopback names.
g): Aliases pointing to aliases.
h): Aliases used outside CNAME RRs.
i): Several hosts with the same IP address.
j): An in-addr.arpa revname owned by several names.

Each of these tests is applied to the following type of records:

TYPE	FIELD	ERROR
----	-----	-----
SOA	origin	a) b) f) h)
NS	domain	a) f)
	server	a) b) c) e) f) h)
CNAME	nickname	a) f)
	host	a) b) c) f) g)
A	host	a) h)
	address	i)
WKS	host	a) b) c) f) h)
	address	d)
HINFO	host	a) b) c) f) h)
MX	name	a) f)
	host	a) b) c) f) h)
TXT	name	a) h)
PTR	revname	h)
	name	a) j)

If msglevel is specified, only those messages belonging to level msglevel are displayed. Default is level 4.

MESSAGES

If incorrect records are found, error messages will be displayed:


Hostname <name> should be in domain notation     (Warning 3)

An address has been found where a name was expected.

For example:
puug.pt. IN NS 192.84.62.1

No A/CNAME records found for <name>              (Warning 2)

The address or the canonical name does not exist for name
(which is referenced in an RR). This name is inside the analyzed zone.

No A/CNAME records found for <name> [Can't verify it]      (Comment)

As above, but in this case the name is outside the analyzed zone.
It is only a comment because we can't guarantee that the zone for this name has been checked.

Perhaps name without trailing dot: <name>        (Warning 2)

This is caused by an eventual missing trailing dot.

For example:
dec4pt.puug.pt.puug.pt. IN A 192.84.62.1

<address>/<name> mismatch in a WKS record        (Warning 3)

There isn't any A RR linking address to name.
Name is inside the analyzed zone(s).

<address>/<name> mismatch in a WKS record [Can't verify it] (Comment)

As above, but name is outside the analyzed zone(s).

Can't verify if NS RRs for <domain> are correct            (Comment)

The zone of domain was not analyzed, so it's impossible
to check if the NSs for the zone of domain match with the NSs defined in the analyzed zone.

NS <server> is not a valid name server for <domain>        (Warning 1)

There are NSs of the delegated zone containing domain that are not defined in the parent zone of this sub-zone as NS.

<server> is not defined as name server for <sub.domain> in <domain>
                                                           (Warning 2)

Server is an authoritative NS for sub.domain but that's not
defined in its parent zone, domain, i.e. the zone that had delegated the authority.

This can introduce a severe problem: <name>      (Warning 1)

This is caused by an MX RR pointing to name, a zone with
name as server or a SOA RR with name in the origin field. Name can be localhost, loopback or 127.0.0.1.

You should avoid the use of this reserved name: <name>     (Warning 3)

A reserved name (localhost or loopback) has been found in an RR (except if the name is an A RR owner or if is one of the situations indicated in the previous message).

Alias <alias> points to another alias: <name> (Comment): Name is an alias (defined in another CNAME RR). Although not illegal and sometimes necessary, you should be sure you really need this since some problems as CNAME loops and bad usage of names (see below) may arise.

Alias alias used where a canonical name should appear (Warning 3): The only place where alias names should be is in CNAME records, otherwise som applications and name servers won't operate correctly. Especially important in the case of MX RRs - see mxc(1).

There are several hosts with address <address>: <name1>, <name2>, ... (Warning 3): The hosts <name1>, <name2>, ..., have the same IP address. This may cause some confusion on users or applications trying to access them or validate their names and addresses, creating security holes. If two names are suppose to have the same IP address (because they represent the same host) the right way to do this is to use CNAME RRs.

There are several names mapped into <revname>: <name1>, <name2>, ... (Warning 3): The same as above, only now the problem is with PTR RRs: <revname> is used in more than one PTR record, with different names as values.

EXAMPLES


$ cat gr | rrc
 ### GR. ###
     Hostname 192.67.249.34. should be in domain notation
     Hostname 147.102.1.1. should be in domain notation

In the master file of the gr zone there are the following records:
  ntua.gr.  86400  IN  NS  192.67.249.34.

  eetaa.gr. 86400  IN  NS  147.102.1.1.
Instead of:
  ntua.gr.         86400  IN  NS  theseas.ntua.gr.
  eetaa.gr.        86400  IN  NS  theseas.ntua.gr.
  theseas.ntua.gr. 86400  IN  A   192.67.249.34
  theseas.ntua.gr. 86400  IN  A   147.102.1.1


$ cat unipg.it | rrc
 ### UNIPG.IT. ###
   No A/CNAME records found for dynslip.unipg.it.

"A" addresses or "CNAME" names for dynslip.unipg.it are absent of the zone. Since this host is inside the zone, there is a reference to a host that doesn't exist (in the DNS database).


$ cat dist.unige.it | rrc 
 ### DIST.UNIGE.IT. ###
   Perhaps name without a trailing dot: *.dist.unige.it.dist.unige.it.

The name *.dist.unige.it doesn't end with a dot in the master file, so it has been expanded with the name of the current $ORIGIN.


$ cat unipd.it | rrc
 ### UNIPD.IT. ###
     147.162.22.2/pdmsa3.unipd.it. mismatch in a WKS record
     147.162.22.205/polar.unipd.it. mismatch in a WKS record

The IP addresses listed in WKS RRs for pdmsa3.unipd.it. and polar.unipd.it. don't match those in the respective A RRs.


$ cat unimi.it | rrc
 ### UNIMI.IT. ###
     Sub-zone dsi.unimi.it. has a NS (hp1.sm.dsi.unimi.it.) that is not defined.

The domain dsi.unimi.it. has a NS (hp1.sm.dsi.unimi.it.) that is not defined in the zone (unimi.it) which had delegated the authority. This can increase unreachability problems.


$ cat trieste.it | rrc
 ### TRIESTE.IT. ###
 NS deccnaf.infn.it. is not a valid name server for icc.trieste.it.

In the zone trieste.it is stated that deccnaf.infn.it is an authoritative NS for sub-zone icc.trieste.it. However according to this sub-zone RRs that was not true. This means that there is a severe inconsistency between the two lists of servers.


$ cat research.ptt.nl | rrc
 ### RESEARCH.PTT.NL. ###
 This can introduce a severe problem: localhost.research.ptt.nl.

There is, for example, an MX RR pointing to localhost.research.ptt.nl. in this zone. This can introduce a problem in mail delivery because, normally, a name like this has address 127.0.0.1.


$ cat puug.pt | rrc
 ### PUUG.PT ###
        Alias ddt.puug.pt. points to another alias: col.puug.pt.

col.puug.pt is not a canonical name, as it might be suggested in the CNAME RR.

$ cat eunet.pt | rrc
### EUNET.PT. ###
Alias dec4pt.eunet.pt. used where a canonical name should appear

The name dec4pt.eunet.pt is an alias for dec4pt.puug.pt. and is listed in the origin of zone eunet.pt.


$ cat sols.pt inesc.pt | rrc
 ### INESC.PT. ###
      There are several hosts with address 146.193.32.200: star.inesc.pt., star.sols.pt.

The A RRs for star.inesc.pt and star.sols.pt both have value 146.193.32.200. This way, a user telneting to star.sols.pt might be greeted with a banner from star.inesc.pt.

$ cat 62.84.192.in-addr.arpa | rrc
### 39.62.84.192.IN-ADDR.ARPA. ###
There are several names mapped into 39.62.84.192.in-addr.arpa: asd.puug.pt., des.puug.pt. RE

There are two PTR RRS for 39.62.84.192.in-addr.arpa, one with asd.puug.pt. and the other with des.puug.pt

AUTHORS

Jorge Frazao <frazao@puug.pt>

Artur Romao <artur@dns.pt>

This document was created by man2html, using the manual pages.
Time: 07:06:34 GMT, May 19, 2025

rrc